jack27121 / stanncam Goto Github PK

The gui is always being compensated to fit in the middle of the screen, maybe it should be an option whether to do so or not. A flag set somewhere

If stanncam.move()'s position happens to overlap the target destination position during movement, the camera will stop moving early before the end of the duration.

they were uncommented long ago, tho i am not sure on what my reasoning. I've since actually been needing it in some of my projects. So should be uncommented and checked that they're working.

It's like room to gui. But just display instead, since display and gui can have different sizes

The X and Y positions of the stanncam do not fully settle on at the follow instance's X and Y positions when using the zoom magnification. The camera position ends up being 2 pixels off from the expected position.

Reproductions steps:

stanncam_init(1920, 1080);
var _cam = new stanncam();
var _player = instance_create_depth(room_width * 0.5, room_height * 0.5, 0, obj_player);
_cam.bounds_w = 0;
_cam.bounds_h = 0;
_cam.follow = _player;
_cam.room_constrain = false;
_cam.zoom(0.25);
repeat (1000) {
    _cam.__step();
}
var __ = {
    camera_x: _cam.x,
    camera_y: _cam.y,
    player_x: _player.x,
    player_y: _player.y,
    assert: (_cam.x == _player.x && _cam.y == _player.y)
};
show_message(__);

right now camera zones can only be rotated 90 degrees or they won't work. They should be able to be rotated any angle.

Also possibly should let zones overlap

If you move or offset a camera with a duration of 0. And in the same step try to use camera.get_x() it won't have updated yet.

move all the view position update stuff into it's own function and call it from all the dynamic move/offset/so on functions.
So all updates happens in the same step when called with a duration of 0

stanncam's can follow object or instances and be given a .move() command while following. If stanncam is following an instance that exists, the follow movement takes priority over any .move() command given.

However, when .move() is given a duration of 0, the camera instantly moves to the given position. If the stanncam is currently following, the camera will quickly jerk back over to the following instance, giving the camera a jittery movement.

When stanncam.__step() is called after having a new stanncam.move() set, the camera will not increase its timer and move the camera. This causes the camera to not move on the first frame during the step.

Issue: When importing the STANNcam into your project via the provided yymps, the files used for STANNcam using the default yyp folder names. In a typical project, these files are going to be spread throughout the default folders.

Fix: Isolate all assets used by STANNcam into their own folder.

Why: This will make it easier for the developer when Creating Local Package, they just export a single folder. It will also make it easier for users of STANNcam to delete the old folder and import the new version.

Side-note: The demo doesn't need to be included in the yymps file. That can be found in the repository, or even the Source Code zip archives in the Release Notes.

Issue: The shake and ease_in_out functions could possibly conflict with functions already in the user's project.

Fix: Rename the functions to be unique to STANNcam

When manually dragging the game window to resize, you can see the display resolution isn't integer values. Either this is a visual error. Or else the window size should be snapped to nearest integer

The window position shouldn't have effect over these values. Just where the camera is drawn relative to the window
https://github.com/jack27121/STANNcam/assets/46312671/566d8629-6a26-4909-86f9-dd47637dd424

The person reporting this also mentioned they're on mac, though if the problem also happens on windows that isn't relevant

If people for whatever reason wants to turn a camera into a 3d one we should let them. I think it should be simplified at first, so don't have to make it fit with the moving zooming and so on functions.

Just being able to set the matrix and apply is enough as a start

it should never be deactivated, adding an error message if it does would be useful to tell exactly how to fix it by adding
instance_activate_object(__obj_stanncam_manager); somewhere if you are deactivating stuff

in windowed mode, changing window size will change the game resolution. But maintain it's aspect ratio

smooth zoom is just supposed to make the zoom happen more smoothly. Without it, it should still function correctly.

basically the opposite of stanncam_init
removes all the cameras, and the manager object, and whatever else there might be

i didn't wanna add more issues, but this cropped up and seemed like an essential feature

should be possible to make, regardless of windowed/fullscreen/borderless windowed

https://gist.github.com/JujuAdams/dcae208b947c337a5e2f55f05bb64fdc
using a simplified version of this (we only care about desktop and consoles right now i reckon)

it's in the stanncam code it's just uncommented

this might work, but haven't tested it

	/// @function room_to_display_x
	/// @description returns the room x position as the position on the display relative to camera
	/// @param {Real} x_
	/// @returns {Real}
	/// @ignore
	static room_to_display_x = function(x_){
		return ((x_-get_y()-x_frac) / get_zoom_x()) * stanncam_get_res_scale_x();
	}

can see that the camera isn't on the center of the player here, it's due to the sprite being drawn has a different rounding than the camera

add - window_get_x()

It's best to adhere to a naming convention and stick with it through your project. Looking at the functions, the parameter names are all over the place. I've seen 3 separate styles: variable, _variable, and variable_.

An object you can place in a level that defines an area where the camera get's constricted within it.
With options to specify which sides of the rectangles that should constraint

So Top and Bottom, would make it so the camera only can go side to side, useful for a corridor or similar in a sidescroller game.

Some drawing functions internally use a surface. and then reset back.

But if you outside the draw function used your own surface, that fucks it up. So they should reset back to whatever surface was used before the drawing functions one

By making adaptive resolution the default, when the resolution doesn't match the game resolution blank space appears even when in windowed mode.

The adaptive resolution should be optional when the system gets initialized

Zoom factors greater than 1 should mean zooming in, thus making things bigger on the screen. The way that STANNcam's zoom factors work is that factors lower than 1 zoom in.

I think reversing how zoom factors work will be more inline with people's expectations when using camera zooms.

Implementing this change should be as simple as flipping a couple of signs. However, making this change can break the zoom controls on existing projects using STANNcam. This change will technically be a major change because it breaks current functionality.

A possible solution to include backwards compatibility would be to add a global flag for which zoom magnification type you want to use.

there's a handful of functions which move the camera over time, you might want to pause those.
So some variable to pause them should be added

https://github.com/jack27121/STANNcam/assets/46312671/c5cf152a-1073-4b05-a37e-0dbf0f52f979
When moving at really low speeds, the camera appears to be stuttering, this could potentially be fixed by having a minimum speed

There's a difference between windowed borderless windowed and fullscreen for some reason

Someone would like it so even in fullscreen/borderless the game maintains whatever resolution is set. So effectively it would be the same size as if the game was in windowed mode, but now it just has a black background.

should be a boolean on the stanncam manager. And get set functions

look at this code, it should set the mouse position to where it already is, but what actually happens is that it gets offset by one pixel up and left

var dx = global.cam.room_to_display_x(global.cam.get_mouse_x() );
var dy = global.cam.room_to_display_y(global.cam.get_mouse_y() );
window_mouse_set(dx,dy);

Some kind of not perfect stretching, some lines have 2 pixels height instead of 1

Glancing at the source code to this library, I immediately notice the definitions inside of stanncam_functions. I am assuming these are the user-facing parts of your library; if so, it would be a good idea to have a consistent naming convention for them to make discoverability easier, and avoid naming conflicts.

For example, sometimes you use cam (in cam_x and cam_y), but then switch to camera other times (in camera_zoom).

My suggestion is to refactor the functions to these names:

toggle_fullscreen          ->  stanncam_toggle_fullscreen
resolution_update          ->  stanncam_update_resolution
screen_shake               ->  stanncam_add_screen_shake
camera_move                ->  stanncam_move
camera_zoom                ->  stanncam_zoom
cam_x                      ->  stanncam_x
cam_y                      ->  stanncam_y
out_cam_bounds             ->  stanncam_out_of_bounds
point_in_rectangle_camera  ->  stanncam_point_in_rectangle
room_to_gui_x              ->  stanncam_room_to_gui_x
room_to_gui_y              ->  stanncam_room_to_gui_y

The application surface is the default drawing method for gamemaker, stanncam turns it off. But it could potentialy be used for the main camera, which is what most people use anyway, Some people are abstaining from stanncam because application_surface is turned off, so might be worth improving!!

The stanncam_ratio_compensate_* functions have the chance to return different values depending on the state of keeping the aspect ratio for STANNcam (stanncam_get_keep_aspect_ratio()).

The state dependence can be extracted from the function. and always return the correct ratio compensate value.

When I scroll down in my game there's a smear effect at the bottom of window.

There should be a black line at the bottom of the wall, as you can see some pixels above.

Here you can see the effect even better.

It wouldn't be that bad if I use pixel perfect scrolling, but my character moves in a smooth grid, so it's very visible while playing.

Any way to prevent this smear effect? I probably could overlay it with my GUI, but I'd rather have the effect gone.

GameMaker in general and a camera library like STANNcam does not use secrets, making the GitGuardian Security Checks unneeded.

with room bounds on the camera view gets constrained to the room size. But the actual camera x and y does not.
I feeeeel like it should

In the function declarations in stanncam you have an @function that causes every variable with the same name to be marked as a function.

example:

I think it would be better if you remove the /// @function in the methods declarations in stancam.

if you toggle fullscreen on/off it might fix it, but it should work on the first go

Buttons and widgets in the example room to change settings would be great.

and in debug mode, maybe to change some variables live as well

tested by importing 2.3.0 into my game project, initializing in one room and then switching to another on the same step (maybe it doesn't matter that it's the same step) breaks the camera

when initing a camera with specific settings, in one long line it becomes incomprehensible to type.
I think having it accept a struct with the specific settings like

var _options ={
 x: 0,
 y: 0,
 width: 400,
 height: 400,
 surface_extra_on: false,
 smooth_draw: false,
 smooth_zoom: false
}

cam1 = new stanncam(_options)

might be better. Waiting for others opinions

starring at the debugger with stanncam you'll notice a very miniscule but steady memory increase, is this perhaps due to a memory leak somewhere? Or the many surfaces being handles inneffeciently.

As a start double check every single surface get's deleted at the end of their run before a new one is created

to roll the camera.

positive roll should rotate the camera counter-clockwise (just like image-angle does it)

Could try to change the view matrix of the camera to rotate. But will have to interact with the rest of the camera system as well.

instead of having super many options being set when initing stanncam some of those could be moved to a settings file