[XP] Custom Resolution

Started by ForeverZer0, November 25, 2010, 03:28:40 am

Previous topic - Next topic

KK20

Which is why this will take a bit more creative thinking than plug-n-play. I did write something that was able to zoom in and out, but moving around bugged the tiles. I also don't think the events were aligned properly. Haven't worked on it in a couple months.

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

LiTTleDRAgo

January 28, 2014, 07:19:32 am #141 Last Edit: February 17, 2014, 01:20:56 am by LiTTleDRAgo
CR map zoom (bugged) : *Link Removed*
CR 0.97 : *Link Removed*
too bad I couldn't get rid the bugs

KK20

Should point out that the Integer class is pointless now. Should have time to look at it tomorrow.

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!


KK20

Just tried out 97a. The Tilemap#ox=/oy= are a bit slower now, the latter being about 3-5 times slower in comparison to 96b.
Code: ox method

0.002 - 0.004
vs
0.003 - 0.006 with the occasional 0.015, which is interesting to note

Code: oy method

0.004 - 0.006
vs
0.011 - 0.025, significant enough to be very noticeable in game


But you implemented a working map zoom, and for which, I am forever grateful to your dedication~

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

LiTTleDRAgo

yeah, I'm aware of that, there are so many calculation needed for the zoom coordinates
also, those differences didn't very noticeable in my OS (both of the 96b and 97a runs at 15-17 FPS in WinXP)

Zexion

Okay so I tried drago's custom resolution out. On my laptop it worked perfectly fine. Same as usual. On my moms... I got like 12 FPS and there wasn't anything on the screen aside from tiles and one event. I switched back to 0.96 and it was fast again o.o  30 FPS

KK20

Well at least it's not only me :P I wonder what's really hitting the performance hard? If it is the zoom calculations, why not devote the sections in v97a to only exist in the Map Zoom Add-on?

I'm using 96b in my Advance Wars for the Tilemap rewrite. Still runs at 39-40 FPS with Fog of War on (that's two instances of Tilemap).

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

Ryex

February 07, 2014, 04:39:12 pm #148 Last Edit: February 07, 2014, 04:44:54 pm by Ryex
allow me to offer my optimization knowledge


while (t = @tile_sprites[col_num]) && (t[0].x/t[0].zoom_x <= -49*t[0].zoom_x || t[0].x/t[0].zoom_x >= -17*t[0].zoom_x) && @anti_hang < 100


this is killing you I bet (not the only thing but a major contributor)
remember it gets run as is every loop. that means t[0] calls t.[](0) and has to resolve the object 6 times every loop. if you bound t[0] to a local name that would provide some speed up.
if you can do the same with the object's .zoom_x and .x properties instead of resolving them off the object with a call every time that might help too.
also you do the same division (t[0].x/t[0].zoom_x) twice, doing it once and binding it to a local name might help (that might need some testing I'm not familiar with the overhead of integer division vs name binding)
next, .zoom_x is a float yes? then your dividing an int by a float. in a typed and compiled language this wouldn't be an issue as the compiler would automatically optimize but in ruby we're doing this all at run time and as an int/float operation is technically impossible for the CPU ruby first has to coerce the int to a float, at run-time, every time it happens. same thign applies for all mathematical operations between floats and ints
lastly the
(t = @tile_sprites[col_num]) &&

while clever in that it is a clean way to set up for the while call, you introduce the somewhat unnecessary testing condition that @tile_sprites[col_num] exists every loop. if you've written everything correctly this condition should NEVER be false and if it can be then something else has gone wrong and you should look into that

all this in mind the line should probably be written as

t = @tile_sprites[col_num]
txf = t.x.to_f
tzoom_x = t.zoom_x
tratio = txf/tzoom_x
while (tratio <= -49.0*tzoom_x || tratio >= -17.0*tzoom_x) && @anti_hang < 100
    #rest of loop code
    #...
    #...
   
    col_num = @corner_index   

    t = @tile_sprites[col_num]
    txf = t.x.to_f
    tzoom_x = t.zoom_x
    tratio = txf/tzoom_x
end #end of while





(($resolution.width + 64)*($resolution.height + 64)).floor / 1024

is there really a float in there that makes the .floor call necessary? in fact if you want an integer result it might be faster to force everything to integer first, there is a reason computers measure power in FLOPS, integer operations are insignificant vs floating point ones. that applies everywhere you end up using floats. drop to integers as soon as you can provided you wont lose needed precision.

Less optimization and more questioning implementation
@tile_sprites[j] && @tile_sprites[j].each_index do |i|

I'm unsure if the objective is to only loop if @tile_sprites[j] exists or if your trying to get a union or intersection of the arrays to loop over. only the former makes sense and I'm unsure of the performance of using an if statement over taking advantage of the way ruby only processes the statement after the && if the first returned a truthy value.
then I question the necessity of once again checking to ensure existence. if the condition really can happen then something else is wrong. and again, it's just one more operation in a loop that adds run time if you don't need it.

summery:
avoid all floating point operations you can.
avoid repeated calls or operations
avoid unnecessary name resolution
avoid implicit coercion at run-time
if you need to do constant checking for existence of an object INSIDE A LOOP then something is wrong elsewhere.

of course you probably should not take my word for all this. do your own tests.

don't take this as a smack down of your skills in any way. everyone has their coding style and ruby is a language where there are 100 ways to do something. it's just not always the fastest. it's taken me years and college classes to learn how to optimize

I'll leave with one final word. never prematurely optimize. only optimize if you NEED to and have profiles to prove that a method or function is eating a significant amount of time.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

KK20

I'll leave that for Drago to do since this is all his doing :P
I never took a good look at the code yet, but that first line...yeah, I can see how performance is lost.

Nice input by the way. Algorithms and/or engine design are kinda my interest now.

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

LiTTleDRAgo

February 07, 2014, 07:51:59 pm #150 Last Edit: February 07, 2014, 09:18:18 pm by LiTTleDRAgo
@kk20
do you have a copy of 0.97a?
I have accidentally updated the pastebin with a bugged 0.97b and I lost ver 0.97a

@ryex
thanks for the input, honestly I didn't know until now that Float have higher cost for performance.

KK20


Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

LiTTleDRAgo

February 07, 2014, 09:05:20 pm #152 Last Edit: February 17, 2014, 01:20:34 am by LiTTleDRAgo
try this (v0.97c) : *Link Removed*

Zexion

February 08, 2014, 01:07:38 am #153 Last Edit: February 08, 2014, 11:58:37 pm by Zexion
I just tryed 0.97c and I get this wierd map glitch o.o
Spoiler: ShowHide


Also, it is VERY laggy at this screen resolution. To be fair though, I tried 0.96b at the same resolution and it's very laggy aswell. I think this laptop just sucks lol. In any case, the map glitch thing still happened

Edit: Also, I tried to use this with the ACE engine thing, and it didn't work. The line it was pointing to was Plane < Sprite
and the error was type mismatch.

LiTTleDRAgo

February 11, 2014, 01:05:09 am #154 Last Edit: February 13, 2014, 11:52:24 am by LiTTleDRAgo
v0.97e = http://pastebin.com/rWLhY7wg

cleaned up code, fix weather, fog & panorama zoom

Zexion

I tried it alone, and it doesn't work o.o I don't know why, but it doesn't.
NoMethodError on line 21 of Spriteset_Map (the default one)
points to this:
    @tilemap.tileset = RPG::Cache.tileset($game_map.tileset_name)

Again, this is with the vxa/xp engine mod only.

Another wierd thing to note, if I use Me(tm) and put it above other scripts, and then put this at the bottom. It works. It's laggy though and idk if the lag is from two tilemap rewrites or if it's the normal lag I would get from your script. At the moment though, I can tolerate the lag because it also fixes the bug that crashes the system when transferring maps.

LiTTleDRAgo

February 15, 2014, 06:26:43 pm #156 Last Edit: February 15, 2014, 06:28:59 pm by LiTTleDRAgo
@^ reuploaded, there are some typo in the script

also, if you're using RGSS3, don't use map larger than 20 x 15 (lags when scrolling) or resolution larger than 640 x 480 (stack to deep)
it seems that RGSS3 engine can't handle a huge number of sprites smoothly

Zexion

February 15, 2014, 06:43:06 pm #157 Last Edit: February 15, 2014, 06:46:38 pm by Zexion
It's kinda a bummer that I can't use bigger maps. I prefer this script over the other (Me tm) because it fixes the random crashing, but the other one had less lag. In any case, what do you recommend I do to get around the 20x15 map restriction? Some maps simply don't make sense to confine to 20x15

Edit: I just test played it, and it seemed to lag less now. Map is 38x46, but there are only two events. I don't know if it will be a problem once there are more events and more sprites on the screen... also forgot to mention that it works alone now :D

LiTTleDRAgo

February 15, 2014, 10:56:07 pm #158 Last Edit: February 17, 2014, 01:19:45 am by LiTTleDRAgo
well, that's ok if you're fine with the lags when the map is scrolling.

Zexion

Well, actually... this last update is way better than before o.o It used to lag a whole lot on all my maps, but now it only stutters a tiny little bit on big maps. (Essentially the same as me(tm)'s) Which is pretty good seeing as it lagged a lot more when I first transferred it over to this laptop with v0.96c and RGSS104E. My moms laptop is significantly slower than mine so the average user should be fine.