Messages

Hum, I need to write the manual entry, but the gist is:

Overlays are unlimited (it used to be possible to have at maximum 20 overlays)
You can move them on screen, set width and height, and transparency. You can also set their Z order.

Other than this you can now access directly the portrait and text overlays used by the engine sierra speech (and other speech modes I think).


Here's an example game to play around:
keysAndCups.zip

Edit: CW answered too, but yeah. That does already makes it useful to do things. Like, I can probably do a cutdown version of my imgi module to provide a scripted hardware accelerated GUI if I remove the scrolling component from that module.

Here's a demo I placed hidden above: https://ericoporto.github.io/agsjs/trees/

Has to be run in a desktop computer with a mouse, WASD walks, C switches in and out of the Ship, mouse movement looks around or set direction. As you click, the game will enter fullscreen, and grab the mouse and set the mouse to infinity mode - this is still a bit hackish in the Web port, so as you exit the fullscreen the mouse will be released and not work in it anymore...

I still need to document this properly (as in put it in the AGS Manual), but in the meantime, information on how to use the Android build available in the Editor is available in this thread: https://www.adventuregamestudio.co.uk/forums/index.php?topic=59772.0

Note: the feature is fairly recent so any questions is better to ask. There's a FAQ in the linked thread, so I recommend checking it, as questions appears I will try to summup things and add there until a manual page is written.

Yeah, Dynamic Sprite DrawImage function.

But seriously, the ordering impacted more in frame rate when going for a low resolution. At low resolution, traversing the array for bubblesort took a ton of time. I attempted a quicksort too, but it did not improve at all (if you search the advanced technical forums I have done a quicksort in AGS script there at some point).

Ordering was very expensive to do on each frame, thus for dynamic sprite based software render in the module there's probably things to investigate in ordering algorithms.

If you feel like playing with the code at a later time, just fork it on GitHub and mess with it, it's possible you will find something interesting through experimenting, then please tell me back.

Oh shoot, do not write things when you are sleepy people... I meant module.

So overlays are faster for two reasons

• You push your bitmap graphic to a texture, and instead of bliting it's pixels from that moment forward you just move the texture on screen, no need to keep reading those pixels every frame
• when drawing things on with sprite drawing, you need to do so in the order, you blitz the sprites from the back and then the ones next until the ones near are drawn, and to do so you need to order the sprites before you can draw then. The ordering is VERY SLOW in AGS Script, it has a great impact on drawing the pixels! When using overlays you can set the ZOrder property and let's the AGS graphics driver do the ordering, which is much faster.

I updated the mode7 plugin module to version 0.3.0.

This introduces DrawObjectOverlays, which will allow rendering using Overlays instead of drawing a sprite. This can be significantly faster, and will allow a lot more objects to be on screen simultaneously.

The web demo has been upgraded to use this method.

I am working on a next version that will introduce big worlds with zoning, shown in the previous screencaps. I do plan a refactor at some point to simplify the API, but I am not sure yet how or when that will happen...

it looks like there are three things going on

• we want the tying of a C or C++ function to a script to be convenient, possibly including being type safe
• we don't care much about performance for the act of making these available to script, since this will happen only once, before the game starts
• script calls to C++ function should have a low overhead, since we know the types of things beforehand, this should not need to figure things out at runtime

We have a similar interface, but the difference is that she also passes the function type along. In her variant this type is defined as a string "i", "iii" and so on.

I feel there has to be some way to leverage compile time introspection through templates that we could use to tie the primitive C++ types to AGS types. Unfortunately whenever I look into these things (like https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error) I kinda fail to grasp how to actually code these stuff...

Sorry, FFI means Foreign Function Interface if I am not mistaken. Usually other languages use iterop when they are talking about this, like here, D about C++: https://dlang.org/spec/cpp_interface.html

About template, I mean like evolving from the issue you describe, it's the last proposition you present in your list, on the top post.

About fuzzie port, you meant the interface here: https://github.com/adventuregamestudio/scummvm/blob/ags/engines/ags/scripting/character.cpp#L2130-L2142 ?
(and that fork, the ags branch could be made the default one in GitHub to make it easier to browse)

https://github.com/adventuregamestudio/ags/issues/1223

I still doesn't understand which type of solution for that you would find acceptable. Like the template approach you mention, would it be accepted?

Or are you looking into the reverse, like the Lua FFI interface (https://luajit.org/ext_ffi.html), which would register C functions to the AGS Script interface, and then it's mostly about exporting the AGS Engine API as C functions. Problem is this second option is not something we could then repurpose for other languages - it would be a new functionality to the script runner.

Looking through AGS code, there's three things there:

• RuntimeScriptValue / macros like API_OBJCALL_VOID, these apparently are the things that would make the C++ function symbol compatible with being imported in the Script Runtime.
• ccAddExternalObjectFunction like functions, makes it possible to access the function symbol from the script runner
• a header for runtime linkage (agsdefns.sh for the internal AGS API)

Usually the modern interpreters doesn't just run the bytecode, they do a previous step where they do something that is like compiling the bytecode, which does some of these checks. AGS Script is not being manipulated in realtime and eval is being run, and it doesn't have reflection.

It could run the bytecode by a second tool before actually executing, which would interpret the bytecode and make sure things when ran are smooth. This is what I mean by not trusting the compiler. There's no need to forego the checking if we can just run it beforehand, at runtime.

About disconnecting the Script Runner, if it was less entrenched in the engine, this would make two things:

• ease with improving it
• reducing the barrier to connect other script runners (e.g.: Lua Jit)

Also just to further explain what I meant before about the YoYo Games Compiler, here's Game Maker Studio:

https://help.yoyogames.com/hc/en-us/articles/235186048-Setting-Up-For-Windows

You can see it can make/run games using VM settings, which is similar to AGS and using YYC, which essentially builds Game Maker Script Language to C++, and then run the resulting code through a C++ Native compiler. This results in a really fast executable. (this would be like building a plugin in AGS, if everything that can be done through scripting could be done through the plugin interface)

I would not trust the compiler as much. I don't think the checks are that burdensome - they only happen at the frontier in the API, which is not what I meant.

Anyway, if I went that route I would just add all relevant event registering to the plugin API, and then compile AGS Script to C++, similar to YACC.

Python, Lua, and most script languages they still detect failures at runtime, so the error checking is not something that has to be removed. What could be done in the script runner is run a step where it looks into the compiled assembly code and workout things that can be done to optimize - like, some instructions I believe could be merged at runtime to leverage a more sensible modern AMD64 instruction.

I am curious if it would be possible to disconnect the AGS Script runner from AGS Engine to be easier to play with it, and then reconnect it back after. I think this would reduce the scope to see what can be optimized in it.

Hi Sugar Beetle!

I hope you have a pleasant time here! Please take some time to look around at the boards, the Community boards are great to interacting and getting a sense of the people here, and technical questions regarding using the AGS Editor goes into the AGS Support boards. Take a look into AGS Games to see what people are making or have made with it. The Creative Production boards are great to participate in too, and we have some tiny competitions we host there!

Pickup a blue cup in the way in.

I was right that I haven't played it but the graphic style is very reminiscent of the Animation Arts games (Lost Horizon and Secret Files) released around the same time which I really enjoyed.

It's really similar looking right? It was so weird that it looked familiar but the actual things pictured were unknown! Glad you figured it out!

I updated the link on the first post with an updated version of this.



You now only have two groups active in the Editor log, which is the Game log group, with things that are reported from the engine internals that are relative to the Adventure game parts, and the Script log group, which are the logs you yourself can output by using System.Log().

The graphics look SO GOOD!!! Also, so many different ways to die! I appreciate the incredible variety! 

video here

On a side note, theoretically speaking AGS is capable of rendering textures in full 3D, that is, for example, it could render a sprite rotated at a given angle along non-z axis, to achieve similar effect as the water in this demo game (or race track in AGS Kart demo game).

Having a hardware accelerated way would make it possible to handle a ton more things in the drawing space!

Once ags itself has the accelerated drawing capabilities, I hope the future module additions though are still useful for the world part - I plan to at some point make a Mode7BigWorld or similar for the object streaming pictured above. (for now though, I don't know the proper API to this so I just started to randomly experiment with the idea yesterday, code here: https://github.com/ericoporto/roading/blob/main/roading/zone_manager.ash)

Spoiler

More stuff on the topic idea... Here's a lod like approach, where far away things get baked in the ground to cheap the drawing process

video here

(maximum limits so far: https://ericoporto.github.io/agsjs/trees/ )

[close]

Hey, thanks everyone for the reception! Again, this would not be possible without Khris original code that made pretty much all the hard math!

I am making a new game to try to stress test this, so I will added some more features to this in a near future. For now, made a 0.2.0 release with some minor additions and fixes.

[@Dualnames]

@Dualnames ❤️❤️❤️

@heltenjon I have a thing for the sea

Thanks! It clarified for me! I also was reading the forum on my phone at the time and I didn't understood what the Desktop only note meant, I just wasn't seeing the images because of this!!

[mode7]

mode7 version 0.3.0

Get Latest Release mode7.scm | GitHub Repo | Download project .zip

AGS Script Module for Mode7 like graphics. See demo in here! (Use Firefox, Safari or Chrome 100+, WASD to move)



This module allows you to project a sprite on the screen with the visual aspect people are familiar from the mode7 graphics of SNES games. Use the Mode7 struct for that!

If you want to do more, and also want to have other elements in it, similar to Mario Kart, you can leverage Mode7World and Mode7Object functionalities.

This code is based on original code that was written by Khris and presented in this ags forum thread. I asked Khris for the original code, which was very Kart oriented, I refactored to what I thought was more generic and made this module in the hopes people could pick around the code and make games out of it!

A note, the original code was a bit more performant, I pulled out some specific optimizations to make the code more flexible.

Script API

Spoiler

Mode7

Mode7.SetCamera

Code: ags

void Mode7.SetCamera(float x, float y, float z, float xa, float ya, float focal_length)

Sets the camera position, angle and focal length.

Mode7.SetViewscreen

Code: ags

void Mode7.SetViewscreen(int width, int height, optional int x,  optional int y)

Sets the screen area it will draw in.

Mode7.SetGroundSprite

Code: ags

void Mode7.SetGroundSprite(int ground_graphic)

Sets the ground sprite, this is the mode7 rendered sprite.

Mode7.SetHorizonSprite

Code: ags

void Mode7.SetHorizonSprite(int horizon_graphic, eHorizonType = eHorizonDynamic)

Sets a sprite that will roll around in the horizon, you can also make it static.

Mode7.SetBgColor

Code: ags

void Mode7.SetBgColor(int bg_color)

Sets the color of the background where the ground sprite doesn't reach.

Mode7.SetSkyColor

Code: ags

void Mode7.SetSkyColor(int sky_color)

Sets the color of the sky.

Mode7.TargetCamera

Code: ags

void Mode7.TargetCamera(float target_x, float target_y, float target_z, float teta_angle, eCameraTargetType camType = eCameraTarget_FollowBehind, bool is_lazy = true)

Target the camera to something.

Mode7.Draw

Code: ags

void Mode7.Draw()

Draws the ground sprite and horizon rendered in the Screen sprite.

Mode7.ResetGround

Code: ags

void Mode7.ResetGround()

Clears the screen sprite.

Mode7.CameraAngleX

Code: ags

float Mode7.CameraAngleX

The camera angle that is normal to the ground plane (e.g.: up and down).

Mode7.CameraAngleY

Code: ags

float Mode7.CameraAngleY

The camera angle that is on the ground plane (e.g.: left and right).

Mode7.Screen

Code: ags

DynamicSprite* Mode7.Screen

The Dynamic Sprite that represents the screen where the Mode7 ground is draw to.



Mode7World
This is an extension of Mode7 and gives you tools to present billboard sprites, positioned in the world coordinates, using the concept of Mode7Objects. You don't have to use it to do the drawing, but it should help you if you want to!

Mode7World.AddObject

Code: ags

Mode7Object* Mode7World.AddObject(int x, int z, float factor, int graphic)

Adds an object, and sets it's x and z position. The y (vertical position) is always zero. You also must pass a scale factor and it's graphics.

Mode7World.AddExternalObject

Code: ags

void Mode7World.AddExternalObject(int x, int z, float factor, int graphic)

Adds an external object that is not managed by the Mode7World. It will still be updated and draw, but removing it from the world will probably not garbage collect it.

Mode7World.RemoveObject

Code: ags

void Mode7World.RemoveObject(int object_i = -1)

Remove a specific object from the world by it's index. If you don't pass a value, it will remove the last valid object added.

Mode7World.RemoveAllsObjects

Code: ags

void Mode7World.RemoveAllsObjects()

Removes all objects from the Mode7 World.

Mode7World.GetAngleObjectAndCamera

Code: ags

int Mode7World.GetAngleObjectAndCamera(Mode7Object* m7obj)

Returns the angle in degrees between the camera and whatever angle is set to a specific object, pointed by their index. Useful when you want to change the graphic of an object based on their relative angle.

Mode7World.UpdateObjects

Code: ags

void Mode7World.UpdateObjects(optional bool do_sort)

Update the screen transform of all objects world positions to their screen positions. You must call it before drawing any objects! You can optionally skip any sorting if you plan rendering using overlays later, since they have zorder property which will be used later by the graphics driver.

Mode7World.DrawObjects

Code: ags

void Mode7World.DrawObjects()

Draws only the objects in the screen sprite. You can use when you need to draw additional things between the ground and the objects. Or when you don't need the ground at all.

Mode7World.DrawObjectsOverlay

Code: ags

void Mode7World.DrawObjectsOverlay()

Draws objects as overlays, without rasterizing at the screen sprite.

Mode7World.DrawWorld

Code: ags

void Mode7World.DrawWorld()

Draws the ground sprite and the objects over it, in the screen sprite.

Mode7World.DrawWorld2D

Code: ags

DynamicSprite* Mode7World.DrawWorld2D()

Gets a dynamic sprite with the world draw in top down view, useful for debugging.

Mode7World.Objects

Code: ags

writeprotected Mode7Object* Mode7World.Objects[i]

Let's you access a specific object in the mode7 world by it's index. Make sure to access a valid position.

Mode7World.ObjectCount

Code: ags

writeprotected int Mode7World.ObjectCount

Gets how many objects are currently in the mode7 world.

Mode7World.ObjectScreenVisibleCount

Code: ags

writeprotected int Mode7World.ObjectScreenVisibleCount

Gets how many objects are actually visible in the screen.

You can iterate through all the screen objects as follows:

Code: ags

for(int i=0; i < m7w.ObjectScreenVisibleCount; i++)
{
  // will make sure to access in order from far to closer
  int index = m7w.ObjectScreenVisibleID[m7w.ObjectScreenVisibleOrder[i]];
  Obj* m7object = m7w.Objects[index];
  
  // do as you you must with you m7object ...
}

Mode7Object
A Mode7Object, you should create objects by using Mode7World.AddObject. After world coordinates are set, you can use Mode7World.UpdateObjects to transform it's coordinates and get updated values in it's Screen prefixed properties.

Mode7Object.SetPosition

Code: ags

void Mode7Object.SetPosition(float x, float y, float z)

A helper function to setting the Object world position in a single line.

Mode7Object.Draw

Code: ags

void Mode7Object.Draw(DrawingSurface* ds)

Draw the object in a DrawingSurface as it would look in a screen.

Mode7Object.X

Code: ags

float Mode7Object.X

Object World X Position on the plane.

Mode7Object.Y

Code: ags

float Mode7Object.Y

Object World Y Position, perpendicular to plane.

Mode7Object.Z

Code: ags

float Mode7Object.Z

Object World Z Position, orthogonal to X position.

Mode7Object.Factor

Code: ags

float Mode7Object.Factor

Object Scaling factor to it's graphics.

Mode7Object.Angle

Code: ags

float Mode7Object.Angle

Object angle, parallel to plane, not used for rendering.

Mode7Object.Graphic

Code: ags

int Mode7Object.Graphic

Object sprite slot, it's width and height is used to calculate the screen coordinates.

Mode7Object.Visible

Code: ags

bool Mode7Object.Visible

Object visibility.

Mode7Object.ScreenX

Code: ags

int Mode7Object.ScreenX

On-Screen Object X position when drawing, if visible. It's regular top, left coordinates, similar to GUI, assumes a Graphic is set.

Mode7Object.ScreenY

Code: ags

int Mode7Object.ScreenY

On-Screen Object Y position when drawing, if visible. It's regular top, left coordinates, similar to GUI, assumes a Graphic is set.

Mode7Object.ScreenWidth

Code: ags

int Mode7Object.ScreenWidth

On-Screen Object Width when drawing, if visible. It's adjusted by the sprite used in Graphic, projection and scaling factor.

Mode7Object.ScreenHeight

Code: ags

int Mode7Object.ScreenHeight

On-Screen Object Height when drawing, if visible. It's adjusted by the sprite used in Graphic, projection and scaling factor.

Mode7Object.ScreenVisible

Code: ags

bool Mode7Object.ScreenVisible

True if object should be drawn on screen. Gets set to false if object is culled when projecting.

Mode7Object.ScreenZOrder

Code: ags

int Mode7Object.ScreenZOrder

ZOrder of the object when drawing on screen, smaller numbers are below, bigger numbers are on top.

[close]

This is just a quick initial release, I plan to update this soon with a better demo and polish the API and other stuff!

• v0.1.0 - initial release.
• v0.2.0 - added ResetGround, CameraAngleX, CameraAngleY to Mode7, added Visible to Mode7Object, added AddExternalObject and DrawWorld2D to Mode7World, change GetAngleObjectAndCamera api.
• v0.3.0 - added support for using Overlays for rendering mode7 objects using Mode7World.DrawObjectsOverlay, and also to skip sorting for overlay based drawing.