LÖVE

The GUI init is left over from my original framework where I was scaling the interface elements and maincam is left over from my initial testing. It's already cleaned up on my local copy.
Thanks for looking into the resize issue so quickly.

Sorry about that, Version 3e uploaded containing fixes for Leif GUI and mouse callbacks.

I love the box climber example !
congratz for CAMERA you did a good job, for sure will look for this in my new project.

someone may have already asked this but cant particle effects be scaled down too?
youd only need to scale the setSize values right?

Hello,

I'm really enjoyed and impressed by the camera.lua features. Good work !
In my game, I need to manage 2 differents things :
- the render part
- the GUI part

The GUI part (see 2) don't need the camera.lua feature, it manage the windows, etc.
In a part of the screen, I show the game (see 1), and I need to be able to move on the map (up/down/right/left) and zoom in/out, like camera.lua do.
My problem was camera.lua change the love function.

So I have made a large number of change. Now my GUI-part and game-part work together.

Now I'm trying to show you my approch, to have a common base and to be able choose if you want that camera.lua do modification in the love functions.

Currently camera.lua :
- create a camera table with camera.love almost like the love structure
- backup some love function in camera.love
- and apply changes on thoses love function

My solution :
- create a camera table with camera.clove
- copy/backup the whole love functions in camera.clove
- set the camera functions in the camera.clove instead of love

After you can choose to use or not the camera.clove or love functions.
To use the camera features everywhere like the original way
put a love = camera.clove in the load() function to override every calls.
To use the camera features only in a function just put local love = camera.clove at the begin of your function.

Additional informations :
- I also add a simple function named camera.class:moveOrigin : - I'm don't really use the camera.lateInit function but it seems running correctly.
- EDIT: I add 2 functions to patch / restore the love functions I'm using them to the begin and the end of the render part, so I don't need to change any drawing functions used by the both part.
Note : In camera.stop I don't use love = camera.love because it override the choice that you can made in the load() by love = camera.clove


I hope you will anderstand me and try to work together.

Best Regards

I thought that when you needed non-scaled drawing you just needed an empty camera, doing no translations, thus acting as the normal functions?

bartbes wrote:I thought that when you needed non-scaled drawing you just needed an empty camera, doing no translations, thus acting as the normal functions?

It's true only if you camera.lua (original version) is alone to modify the love functions.
In my case it intercepts the draw functions (like camera) to allow to draw with "z-index".

It's better to keep love function clean isn't it ?

I don't think we can have anything but the overriding since it would require so much code change in projects. One of the nice features with camera is that it pretty much works just by including the file. Now that there are several libraries overriding the love.-functions, I think one would rather want to develop a framework for making them work together. For instance by registering the overrides with different priorities and having a framework love.-function manage the calling.

Camera is however licensed under "the lovely public community license" and you may freely update it as you wish, e.g. like the wiki page. If others disagree, they may choose to challenge your changes or revert altogether. If there's a problem, discuss. First discussing significant changes like these is appreciated. If noone complains, go ahead and implement the changes. Simpler changes like the MoveOrigin function, just go ahead and add at once. Also see (and/or extend) http://love2d.org/wiki/index.php?title= ... ource_code.

I'm not sure why the problem arises for you. Even if you also override the love.-functions, as long as the camera is the empty camera, everything should just be passed along unchanged. If Camera or your functions processes it first should not matter.

This is a great module though I would like to ask for some clarification on a certain subject as the wiki entry has some ambiguous verbiage that doesn't help to explain a certain functionality.

My inquiry is of the apparent change in working with mouse coordinates that I've seen from an old build from January to the most recent build. In the old build love.mouse.getX() (For example), when the camera is set to my general world camera, would return coordinates of the arbitrary units that CAMERA uses, for clarification let us call these CU for CAMERAunit. The old functionality was that calling a mouse position function would return coordinates of the mouse relative to its position in the window but it would use CU instead of pixels to describe its position. I got used to this.

The new functionality however returns mouse position as coordinates of the mouse in the game-world in CU, and using pos() would translate this into coordinates relative to the window but in pixels. This functionality makes sense as unpos() is used to convert from pixel coordinates and returns in-game CU.

Now my question is; is there a way to convert in-game CU coordinates to CU coordinates that are relative to the window?

Again, this might be explained by using setMouseCamera() but the wording of the documentation doesn't explain it in such a way I can understand.

A description of context:

I'm trying to convert the camera system that I've written for the old design to be used with the new CAMERA, but here's where it gets snagged:

OLD(pseudocode): CUR = CAMERAunits relative to the camera
CUA = CAMERAunits absolute definition in the world

The intent was to have the center of the screen be between the mouse and the player so that the camera doesn't stagnate centering on the player but instead follows the mouse to an extent to show more of the world. This implementation worked at the time because mouse positions returned were relative to its position on screen. It even worked with scaling. If the mouse is never moved, then the value is never changed and the mouse stays a constant distance from the player. The scrolling was super smooth when it was done this way.

NEW(pseudocode): With the new way I've had to average the distance of two absolute CU coordinates to find the middle. This works as intended, but now that even without moving the mouse around, when the player moves the mouse coordinates change. I'm not sure if it's originating from the fact that when one moves the mouse, since the origin moves as well, when the screen moves it also repositions the mouse. What it ends up looking like is that there's a lag when beginning mouse movement and a damping effect when mouse movement is supposed to have stopped for a few frames after the fact. Also, when falling, the origin and player deviates a bit in relation to the mouse.

This is a really hard problem to describe without being able to actually move the mouse and feel the difference in tactile response.

Any help would be appreciated.

TST: nice game. o.0 I want to play!