jack27121 / stanncam Goto Github PK
View Code? Open in Web Editor NEWAn easy to use camera object for Gamemaker studio, with options to change game and GUI resolution independently, and upscale pixelart
License: MIT License
An easy to use camera object for Gamemaker studio, with options to change game and GUI resolution independently, and upscale pixelart
License: MIT License
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
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();
}
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
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
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);
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.