MODULE: mode7 0.3.0

[Crimson Wizard]

Overlays happened to be the most useful kind of object in todays AGS when you need a large number of moving and transformed (scaled etc) sprites on screen.
* overlays are designed unlimited (limited only by the program memory)
* they are rendered as a texture and thus accelerated by the graphics card (if you run with Direct3D / OpenGL render).
* it's a tiny structure without any superfluous properties that may screw logic up if not taken care of.

Before 3.6.0 room objects and characters could be more performant, as overlays did not support scaling for some reason, but since 3.6.0 beta Overlays may be scaled too
(https://www.adventuregamestudio.co.uk/forums/index.php?topic=59842.msg636645302#msg636645302)

PS. There's currently a serious issue remaining with overlays that they don't share a sprite reference, but make a bitmap copy; i believe this should be taken care of in the future.

[Snarky]

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.

Ah, so when working with overlays you just set the Z-order to be the distance, and the driver takes care of the sorting. I was thinking of the Z-order as the sorting order, and figured you would still need to re-sort them whenever you moved.

I think you could probably optimize something similar for the draw sorting, where you build the sort order as you calculate the object distances (and possibly leverage the idea that most things will remain in the same order as in the last frame), but clearly that adds a lot of complexity.

[abstauber]

This module + demo games really looks super cool. I'd never thought to see mode7 that fluent with just plain AGS script.
But there's more to it than just drawing on an overlay instead of a room's surface, right?


And is there a particular thread discussing the new possibilities with overlays? All I remember is that when I did my weather module back in 2008, overlays were rather limited.

[Crimson Wizard]

And is there a particular thread discussing the new possibilities with overlays?

There's not that much to mention, this is a relevant part of the change list (you may find it in the 3.6.0 release thread):

- Added Overlay.Width and Height properties, that let you freely scale existing Overlay.
- Added readonly Overlay.GraphicWidth and GraphicHeight properties that let read original overlay's graphic size (for textual overlays too).
- Added Overlay.Transparency property.
- Added Overlay.ZOrder property that lets you sort Overlays on screen among themselves and GUI.

EDIT: oh right, and also quite important

- Removed Overlay limit.

So basically overlays at the moment are the only graphical object in game that a) is not limited b) may be created and deleted in script.

[eri0o]

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...

[abstauber]

Ah okay, thanks for the clarification.
I might have some more question, but I'll start a separate thread.

Back to topic

[RootBound]

Hey mods, I hope it's OK to ask questions about a module that hasn't been commented on in over a year.

I'm trying to experiment with the module and having difficulty.

Right now I'm just trying to set a ground sprite and get it to be visible when I run the game. Nothing else yet.

I started with the blank game template, one empty room, and a player character with no sprite, set to start in the empty room. Then I imported a single ground sprite (slot 1).

I wrote this code, based on my best understanding of the script API detailed in the original post above:

Code: ags

// room script file

Mode7 ThePlace;

function room_Load()
{
  ThePlace.SetViewscreen(640, 180, 0, 0); //should cover half of screen. I'm assuming 0,0 places top left corner of drawing in top left corner of game viewport screen. Tried it at 320, 180 (center of screen) as well, with no difference in effect.
  ThePlace.SetGroundSprite(1); //some green ground
  ThePlace.SetCamera(0.0, 0.0, 0.0, 0.0, 0.0, 0.0); //This will turn out to be a problem, but changing it all to 1.0 doesn't fix everything.
  ThePlace.Draw();
}

First I get an error saying sprite 19 doesn't exist. I wonder where this is called from and find it in line 111 of the Mode7 script. Not sure what that's about. I import 18 more sprites, all unique, then run again.

This time I get an error saying line 222 is dividing by zero. I look there and see it seems related to the camera. Change all camera values to one, like so:

Code: ags

Mode7.SetCamera(1.0, 1.0, 1.0, 1.0, 1.0, 1.0);

This time the game runs but I still just get a black screen with nothing drawn. Did I miss a command?

[Khris]

@RootBound

The signature of the SetCamera method is

Code: ags

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

x,y,z is the position, so y should be greater than 0 or the camera is inside the plane.

xa and ya are the camera angles, i.e. xa determines the direction the camera is facing, ya is the up/down angle afaik.
xa can be anything from 0 to 2 * Pi, but values outside that range should wrap around. ya is supposed to be something like -0.1 for instance, i.e. the camera is slightly looking down.

The last value is the focal length, essentially a zoom factor. Try values like 35.0.

[RootBound]

Hi @Khris thanks so much for the response. I tinkered with the values (also tried changing the ground sprite in case that was causing the problem) and unfortunately I am still just getting a black screen.

Here's the entirety of the room code:

Code: ags

// room script file

Mode7 ThePlace;

function room_Load()
{
  ThePlace.SetViewscreen(100, 100, 100, 100);
  ThePlace.SetGroundSprite(17);
  ThePlace.SetCamera(10.0, 10.0, 10.0, 1.0, -0.1, 35.0);
  ThePlace.Draw();
  
}

Any other errors you see? I appreciate it.

[Khris]

The .Draw() call goes into room_RepExec; other than that I don't see an error.
The SetViewScreen command expects x, y, width and height, so setting all to 100 should work.

[RootBound]

Thanks @Khris. I put the Draw() in room_RepExec, and I imported a very simple background image to the room just to make sure the room is actually loading. It does fade in, but no mode7 objects are drawn. @eri0o do you have any thoughts?

[Khris]

Maybe the camera position and angle causes the mode7 ground to be off-screen?

Try

Code: ags

 ThePlace.SetCamera(0.0, 10.0, 0.0, 0, -0.1, 100.0);

[newwaveburritos]

I think there are some debug keys you can use to move the camera around.  I, K, O, L all do something with the camera at least in the demo.  Arrow keys, too.

[RootBound]

@Khris No change unfortunately.
@newwaveburritos Didn't get a response from the debug keys either. I saw you're making your own game with mode7. What did you use as your starting base? Did you use a template and then add the module?

[Khris]

Those keys only work if they are handled accordingly, which isn't the case with just the module.

Not sure how to debug this tbh; can you maybe start with the demo game instead?

[newwaveburritos]

I definitely worked backwards from the demo rather than forward from the module.

[RootBound]

Thanks, both of you. The issue I was having with working backwards from the demo is that there is so much there that I don't know what is needed.

All I want is to create a mode7 ground object(?) that I can move across in one direction at several different (controllable) speeds, and to be able to track the mode7 camera coordinates so that I can teleport the camera back to the start when the camera reaches a certain point, and then change the ground texture. I don't need the boat or the sky or the 360 degree movement or even keyboard control.

This feels like it should be doable with the module but I don't know where to start with the whole demo in place.

[Khris]

I found the missing piece: the module only draws to its DynamicSprite, and you have to draw that to the room:

Code: ags

function room_RepExec()
{
  ThePlace.Draw();
  DrawingSurface* ds = Room.GetDrawingSurfaceForBackground();
  ds.DrawImage(0, 0, ThePlace.Screen.Graphic);
  ds.Release();
}

[RootBound]

I found the missing piece: the module only draws to its DynamicSprite, and you have to draw that to the room:

IT WORKS!!!        Now I can actually start experimenting!

Amazing. Thanks a million.

[RootBound]

EDIT: turns out this has nothing to do with the background, actually. This is the "sprite 19" issue from my original post. Sprite 19 was the same as the background image. Easy workaround is to make sprite 19 transparent. Doesn't solve the underlying issue, but it works.

Something extremely strange is happening. It appears that a copy of the room background image (in this case two color blocks) is being drawn on top of the mode7 ground texture. Could this an issue with GetDrawingSurfaceForBackground, or do you think the mode7 module is not drawing the texture correctly?