Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full Resolution changes #249

Merged
merged 5 commits into from
Jun 6, 2014
Merged

Full Resolution changes #249

merged 5 commits into from
Jun 6, 2014

Conversation

Lobomon
Copy link
Member

@Lobomon Lobomon commented Jun 6, 2014

this will keep all as it was it the resolution patch is not set,

to set it change the defaul resolution to 640 x 480 and the tile size to 32

@take-cheeze
Copy link
Member

At least in cache checker it shouldn't use SCREEN_TARGET_* since its values is from the spec.

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

Well that depends, because on a 640 x 480 screen resolution the title should be 640 x 480, bigger screen bigger resources, this is not expected to work by default old games

@take-cheeze
Copy link
Member

At least in RPG Maker 2k the screen size is fixed and other material size is based on it.
Using SCREEN_* just makes it less readable.
And I won't use RPG Maker 2k cache system in other screen size.

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

What do you propose ? if that is not changed bigger resources are not recognized

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

Having fixed sizes for each resolution would require a lot of rework , and haven an screen multiplier does not work for wide screen resolutions

@Ghabry
Copy link
Member

Ghabry commented Jun 6, 2014

I agree with take_cheeze that the cache-part should be reverted.
The spec is not enforced, you only get a Debug log.

(Oh and please just add a new commit, don't squash/amend/rebase)

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

Done,

@take-cheeze
Copy link
Member

@Lobomon Thanks. 👍

@@ -433,7 +433,7 @@ void TilemapLayer::GenerateAutotileD(short ID) {
for (int j = 0; j < 2; j++)
for (int i = 0; i < 2; i++)
for (int k = 0; k < 2; k++) {
quarters_hash <<= 4;
quarters_hash <<= 4;//multiply 16
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that 4 correct or is it independend from the tilesize?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that is normal, that code actually manage the quarts of a tile so yes the number is the same on each resolution

@Ghabry
Copy link
Member

Ghabry commented Jun 6, 2014

Gets my approvement. Because it's a hugher change I will keep it open for discussion in case fdela or others want to say something...

Minor issue: You introduced many superfluous braces like ((SCREEN_TARGET_HEIGHT-80)).

@Zegeri
Copy link
Member

Zegeri commented Jun 6, 2014

Here's a test project:
https://dl.dropboxusercontent.com/u/30277047/SimpleLobomon.zip

Walk down and you'll notice that the screen scrolls down too soon.

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

Zegeri what is the exact problem ? do you have an screen shot of the issue ?

@Zegeri
Copy link
Member

Zegeri commented Jun 6, 2014

Of course. In RPG_RT, the screen scrolls down for the first time when the player crosses the white line. But in your branch, the screen scrolls when the player crosses the brown line. screenshot

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

I just notice the problem that Zegeri comments, there is a bub on the scroll when the 2x resolution is not active, the time to scroll changes from 1/2 of the screen to 1/4

@Zegeri
Copy link
Member

Zegeri commented Jun 6, 2014

Here's a video of Yume Nikki using your branch's easyrpg-player.
https://mediacru.sh/OQR2zU8UuFI6

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

The last commit fixes that issue

@Zegeri
Copy link
Member

Zegeri commented Jun 6, 2014

Some Main Menus are rendered incorrectly (left master branch/right lobomon's branch):
beforeafter

Actually, both are inaccurate when compared with the original one (#49).
http://blog-imgs-19-origin.fc2.com/a/n/n/annkokunokizinn/suneternity00164.jpg
So, I guess this is not a big deal.

@Zegeri
Copy link
Member

Zegeri commented Jun 6, 2014

In large maps, the screen isn't always centered on the playable character. This didn't use to happen.
Left RPG_RT.exe/Right Lobomon's branch.
Game: Jay's Journey, but it happens in any game with large maps.
rpg_rtlobomon2

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

Can I get a sample project for the problem that just mention about the center ?

@Zegeri
Copy link
Member

Zegeri commented Jun 6, 2014

@MarianoGnu
Copy link
Member

I warned before but i'll repeat it here: Some games have command events calculations using event's screen locations, depending on how they are managed, widescreen could break some engines.

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

I fixed the problems for the center,

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

Mariano those games wont ever work at Hi resolution, so we wont support them, and will keep working as long as the resolution be the default.

@Ghabry
Copy link
Member

Ghabry commented Jun 6, 2014

I don't really care about that high resolution stuff. I only don't want to see breakage of "native" resolution ;)

@Lobomon
Copy link
Member Author

Lobomon commented Jun 6, 2014

You should care, what is the differences between the easy and the much older released on 2000 RM2k then ? besides the port it does not provide any new feature ...

@Ghabry
Copy link
Member

Ghabry commented Jun 6, 2014

besides the port it does not provide any new feature
That is fine for me... And we support 32bit g

@@ -47,7 +47,7 @@ Scene_Map::Scene_Map(bool from_save) :

void Scene_Map::Start() {
spriteset.reset(new Spriteset_Map());
message_window.reset(new Window_Message(0, 240 - 80, 320, 80));
message_window.reset(new Window_Message(0, SCREEN_TARGET_HEIGHT - 80, SCREEN_TARGET_WIDTH, 80));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This stretches the message window to full screen width. Sure you want this? (instead of centering)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well it is the first resolution patch, for now that is ok, on future versions the font and the size must be adjusted.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look, before the changes we just had numbers but not what it actually represent now the calculations are like this,

The total size of the HEIGHT -the size of the window(80)

The 80 value should be dynamic based on the resolution, but of curse that wont be calculated at this iteration.

fdelapena added a commit that referenced this pull request Jun 6, 2014
@fdelapena fdelapena merged commit 73ed4dc into EasyRPG:master Jun 6, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

6 participants